home *** CD-ROM | disk | FTP | other *** search
/ Hacker's Arsenal - The Cutting Edge of Hacking / Hacker's Arsenal - The Cutting Edge of Hacking.iso / texts / unixseccheck.txt < prev    next >
Text File  |  2001-07-11  |  19KB  |  357 lines
  1.  
  2.  
  3. -----BEGIN PGP SIGNED MESSAGE-----
  4.  
  5. ==============================================================================
  6. UNIX Computer Security Checklist (Version 1.1)       Last Update   19-Dec-1995
  7. ==============================================================================
  8. The Australian Computer Emergency Response Team has developed a checklist which
  9. assists in removing common and known security vulnerabilities under the UNIX
  10. Operating System.  It is based around recently discovered security
  11. vulnerabilities and other checklists which are readily available (see 
  12. references in Appendix C). 
  13.  
  14. This document can be retrieved via anonymous ftp from:
  15.    ftp://ftp.auscert.org.au/pub/auscert/papers/unix_security_checklist
  16.  
  17. For information about detecting or recovering from an intrusion, see the
  18. CERT security information document which can be retrieved via anonymous ftp
  19. from:
  20.    ftp://ftp.auscert.org.au/pub/cert/tech_tips/security_info
  21.  
  22. It is AUSCERT's intention to continue to update this checklist.  Any
  23. comments should be directed via email to auscert@auscert.org.au.  Before
  24. using this document, ensure you have the latest version.  New versions of this
  25. checklist will be placed in the same area on the ftp server and should be 
  26. checked for periodically. 
  27.  
  28. In order to make effective use of this checklist, readers will need to have 
  29. a good grasp of basic UNIX system administration concepts.  Refer to C.9 and 
  30. C.10 for books on UNIX system administration.
  31.  
  32. If possible, apply this checklist to a system before attaching it to a network.
  33.  
  34. In addition, we recommend that you use the checklist on a regular basis as well
  35. as after you install any patches or new versions of the operating system, with
  36. consideration given to the appropriateness of each action to your particular
  37. situation. 
  38.  
  39. Command examples have been supplied for BSD-like and SVR4-like systems (see
  40. Appendix F for operating system details and Appendix G for command details). 
  41. Full directory paths and program options may vary for different flavours of
  42. UNIX. If in doubt, consult your vendor documentation. 
  43.  
  44. For ease of use, the checklist has been organised into separate, logically
  45. cohesive sections.  All sections are important.  An abbreviated version of
  46. this checklist can be found in Appendix D. 
  47.  
  48. CHECKLIST INDEX:        1.0  Patches
  49.                         2.0  Network security
  50.                         3.0  ftpd and anonymous ftp
  51.                         4.0  Password and account security
  52.                         5.0  File system security
  53.                         6.0  Vendor operating system specific security
  54.                         7.0  Security and the X Window System
  55.     
  56. APPENDICES:      Appendix A  Other AUSCERT information sources
  57.                  Appendix B  Useful security tools
  58.                  Appendix C  References
  59.                  Appendix D  Abbreviated Checklist
  60.                  Appendix E  Shell Scripts
  61.                  Appendix F  Table of operating systems by flavour
  62.                  Appendix G  List of commands by flavour
  63.  
  64. Any trademarks which appear in this document are registered to their
  65. respective owners.
  66.  
  67. ==============================================================================
  68. 1.0  Patches 
  69. ==============================================================================
  70.    *    Retrieve the latest patch list from your vendor and install any 
  71.         patches not yet installed that are recommended for your system.
  72.             Some patches may re-enable default configurations.  For this 
  73.             reason, it is important to go through this checklist AFTER
  74.             installing ANY new patches or packages.
  75.    *    Details on obtaining patches may be found in Section 6.
  76.    *    Verify the digital signature of any signed files.  Tools like PGP may 
  77.         be used to sign files and to verify those signatures.
  78.         (Refer to B.15 for PGP access information).
  79.    *    If no digital signature is supplied but an md5(1) checksum is supplied,
  80.         then verify the checksum information to confirm that you have retrieved 
  81.         a valid copy.
  82.         (Refer to B.10 for MD5 access information).
  83.    *    If only a generic sum(1) checksum is provided, then check that.  Be
  84.         aware that the sum(1) checksum should not be considered secure.
  85.  
  86. ==============================================================================
  87. 2.0  Network security
  88. ==============================================================================
  89.         The following is a list of features that can be used to help
  90.         prevent attacks from external sources.
  91.  
  92.  2.1  Filtering
  93.    *    ENSURE that ONLY those services which are required from outside your 
  94.         domain are allowed through your router filters.
  95.             In particular, if the following are not required outside your
  96.             domain, then filter them out at the router.
  97.  
  98.              NAME     PORT  PROTOCOL            NAME    PORT  PROTOCOL
  99.  
  100.              echo     7     TCP/UDP             login   513   TCP
  101.              systat   11    TCP                 shell   514   TCP
  102.              netstat  15    TCP                 printer 515   TCP
  103.              bootp    67    UDP                 biff    512   UDP
  104.              tftp     69    UDP                 who     513   UDP
  105.              link     87    TCP                 syslog  514   UDP
  106.              supdup   95    TCP                 uucp    540   TCP
  107.              sunrpc   111   TCP/UDP             route   520   UDP
  108.              NeWS     144   TCP                 openwin 2000  TCP
  109.              snmp     161   UDP                 NFS     2049  UDP/TCP
  110.              xdmcp    177   UDP                 X11     6000 to 6000+n TCP
  111.              exec     512   TCP                 (where n is the maximum number
  112.                                                  of X servers you will have)
  113.  
  114.         Note: Any UDP service that replies to an incoming packet may be 
  115.               subject to a denial of service attack.
  116.  
  117.         See CERT advisory CA-95.01 (C.8) for more details.
  118.  
  119.         Filtering is difficult to implement correctly.  For information on
  120.         packet filtering, please see Firewalls and Internet Security (C.6)
  121.         and Building Internet Firewalls (C.7).
  122.  
  123.  2.2  "r" commands
  124.  
  125.   2.2.1 If you don't NEED to use the "r" commands...
  126.    *    DO disable all "r" commands (rlogin, rsh etc.) unless specifically 
  127.         required.
  128.             This may increase your risk of password exposure in network
  129.             sniffer attacks, but "r" commands have been a regular source of 
  130.             insecurities and attacks.  Disabling them is by far the lesser of 
  131.             the two evils (see 2.9.1).
  132.  
  133.   2.2.2 If you must run the "r" commands...
  134.    *    DO use more secure versions of the "r" commands for cases where 
  135.         there is a specific need.
  136.             Wietse Venema's logdaemon package contains a more secure version
  137.             of the "r" command daemons.  These versions can be configured to 
  138.             consult only /etc/hosts.equiv and not $HOME/.rhosts.  There is 
  139.             also an option to disable the use of wildcards ('+').
  140.         Refer to B.13 for access information for the logdaemon package
  141.    *    DO filter ports 512,513 and 514 (TCP) at the router if you do use any
  142.         of the "r" commands.
  143.             This will stop people outside your domain from exploiting these
  144.             commands but will not stop people inside your domain.
  145.             To do this you will need to disable these commands (see 2.2.1).
  146.    *    DO use tcp_wrappers to provide greater access and logging on these
  147.         network services (see 2.12).
  148.  
  149.  2.3  /etc/hosts.equiv
  150.  
  151.   2.3.1 It is recommended that the following action be taken whether or not 
  152.         the "r" commands are in use on your system.
  153.      *    CHECK if the file /etc/hosts.equiv is required.   
  154.               If you are running "r" commands, this file allows other hosts to 
  155.               be trusted by your system.  Programs such as rlogin can then be 
  156.               used to log on to the same account name on your machine from a 
  157.               trusted machine without supplying a password.
  158.               If you are not running "r" commands or you do not wish to 
  159.               explicitly trust other systems, you should have no use for
  160.               this file and it should be removed.  If it does not exist, it 
  161.               cannot cause you any problems if any of the "r" commands are 
  162.               accidentally re-enabled.
  163.  
  164.   2.3.2 If you must have a /etc/hosts.equiv file
  165.      *    ENSURE that you keep only a small number of TRUSTED hosts listed. 
  166.      *    DO use netgroups for easier management if you run NIS (also known 
  167.           as YP) or NIS+.
  168.      *    DO only trust hosts within your domain or under your management.
  169.      *    ENSURE that you use fully qualified hostnames, 
  170.               i.e., hostname.domainname.au
  171.      *    ENSURE that you do NOT have a '+' entry by itself anywhere in the
  172.           file as this may allow any user access to the system.
  173.      *    ENSURE that you do not use '!' or '#' in this file.
  174.               There is no comment character for this file.
  175.      *    ENSURE that the first character of the file is not '-'.  
  176.           Refer to the CERT advisory CA-91:12 (C.8).
  177.      *    ENSURE that the permissions are set to 600.
  178.      *    ENSURE that the owner is set to root.
  179.      *    CHECK it again after each patch or operating system installation.
  180.  
  181.  2.4  /etc/netgroup
  182.    *    If you are using NIS (YP) or NIS+, DO define each netgroup to contain 
  183.         only usernames or only hostnames.
  184.             All utilities parse /etc/netgroup for either hosts or
  185.             usernames, but never both.  Using separate netgroups makes it
  186.             easier to remember the function of each netgroup. The added
  187.             time required to administer these extra netgroups is a small
  188.             cost in ensuring that strange permission combinations have not
  189.             left your machine in an insecure state.
  190.             Refer to the manual pages for more information.
  191.  
  192.  2.5  $HOME/.rhosts
  193.  
  194.   2.5.1 It is recommended that the following action be taken whether or not 
  195.         the "r" commands are in use on your system.
  196.       *     ENSURE that no user has a .rhosts file in their home directory.
  197.                They pose a greater security risk than /etc/hosts.equiv, as one
  198.                can be created by each user.  There are some genuine needs for
  199.                these files, so hear each one on a case-by-case basis; e.g.,
  200.                running backups over a network unattended.
  201.       *     DO use cron to periodically check for, report the contents of 
  202.             and delete $HOME/.rhosts files.  Users should be made aware that 
  203.             you regularly perform this type of audit, as directed by policy.
  204.  
  205.    2.5.2 If you must have such a file
  206.       *    ENSURE the first character of the file is not '-'.  
  207.            Refer to the CERT advisory CA-91:12 (C.8).
  208.       *    ENSURE that the permissions are set to 600.
  209.       *    ENSURE that the owner of the file is the account's owner.
  210.       *    ENSURE that the file does NOT contain the symbol "+" on any line as
  211.            this may allow any user access to this account.
  212.       *    ENSURE that usage of netgroups within .rhosts does not allow
  213.            unintended access to this account.
  214.       *    ENSURE that you do not use '!' or '#' in this file.
  215.               There is no comment character for this file.
  216.       *    REMEMBER that you can also use logdaemon to restrict the use of
  217.            $HOME/.rhosts (see 2.2.2).
  218.  
  219.  2.6  NFS
  220.       When using NFS, you implicitly trust the security of the NFS server
  221.       to maintain the integrity of the mounted files.
  222.    *    DO filter NFS traffic at the router.
  223.             Filter TCP/UDP on port 111 
  224.                    TCP/UDP on port 2049 
  225.             This will prevent machines not on your subnet from accessing
  226.             file systems exported by your machines.
  227.    *    DO apply all available patches.
  228.             NFS has had a number of security vulnerabilities.
  229.    *    DO disable NFS if you do not need it.
  230.             See your vendor supplied documentation for detailed instructions.
  231.    *    DO enable NFS port monitoring.
  232.             Calls to mount a file system will then be accepted from ports < 1024
  233.             only. This will provide added security in some circumstances.
  234.             See your vendor's documentation to determine whether this is an 
  235.             option for your version of UNIX (see also 6.1.8 and 6.2.4).
  236.    *    DO use /etc/exports or /etc/dfs/dfstab to export ONLY the file systems 
  237.         you need to export. 
  238.             If you aren't certain that a file system needs to be exported, 
  239.             then it probably shouldn't be exported.
  240.    *    DO NOT self-reference an NFS server in its own exports file.
  241.             i.e., The exports file should not export the NFS server to
  242.             itself in part or in total.  In particular, ensure the NFS server 
  243.             is not contained in any netgroups listed in its exports file. 
  244.    *    DO NOT allow the exports file to contain a 'localhost' entry.
  245.    *    DO export to fully qualified hostnames only.
  246.             i.e., Use the full machine address 'machinename.domainname.au' and
  247.             do not abbreviate it to 'machinename'.
  248.    *    ENSURE that export lists do not exceed 256 characters.
  249.             If you have access lists of hosts within /etc/exports, the list 
  250.             should not exceed 256 characters AFTER any host name aliases have 
  251.             been expanded.
  252.             Refer to the CERT Advisory CA-94:02 (C.8).
  253.    *    DO run fsirand for all your file systems and rerun it periodically.
  254.             Firstly, ensure that you have installed any patches for fsirand.
  255.             Then ensure the file system is unmounted and run fsirand. 
  256.             Predictable file handles assist crackers in abusing NFS. 
  257.    *    ENSURE that you never export file systems unintentionally to the world.
  258.             Use a -access=host.domainname.au option or equivalent in 
  259.             /etc/exports. 
  260.             See the manual page for "exports" or "dfstab" for further examples.
  261.    *    DO export file systems read-only (-ro) whenever possible.  
  262.             See the manual page for "exports" or "dfstab" for more information.
  263.    *    If NIS is required in your situation, then DO use the secure option in
  264.         the exports file and mount requests (if the secure option is available).
  265.    *    DO use showmount -e to see what you currently have exported.
  266.    *    ENSURE that the permissions of /etc/exports are set to 644.
  267.    *    ENSURE that /etc/exports is owned by root.  
  268.    *    ENSURE that you run a portmapper or rpcbind that does not forward 
  269.         mount requests from clients.
  270.             A malicious NFS client can ask the server's portmapper daemon 
  271.             to forward requests to the mount daemon.  The mount daemon 
  272.             processes the request as if it came directly from the portmapper.
  273.             If the file system is self-mounted this gives the client 
  274.             unauthorised permissions to the file system.
  275.             Refer to section B.14 for how to obtain an alternate portmapper or
  276.             rpcbind that disallow proxy access.
  277.             Refer to the CERT Advisory 94:15 (C.8).
  278.    *    REMEMBER that changes in /etc/exports will take effect only after
  279.         you run /usr/etc/exportfs or equivalent. 
  280.  
  281.    Note: A "web of trust" is created between hosts connected to each other via
  282.          NFS.  That is, you are trusting the security of any NFS server you use.
  283.  
  284.  2.7  /etc/hosts.lpd
  285.    *    ENSURE that the first character of the file is not '-'.  
  286.         (Refer to the CERT advisory CA-91:12 (see C.8)).
  287.    *    ENSURE that the permissions on this file are set to 600.
  288.    *    ENSURE that the owner is set to root.
  289.    *    ENSURE that you do not use '!' or '#' in this file.
  290.             There is no comment character for this file.
  291.  
  292.  2.8  Secure terminals
  293.    *    This file may be called /etc/ttys, /etc/default/login or
  294.         /etc/security.  See the manual pages for file format and usage 
  295.         information.
  296.    *    ENSURE that the secure option is removed from all entries that 
  297.         don't need root login capabilities. 
  298.             The secure option should be removed from console if you do not 
  299.             want users to be able to reboot in single user mode.
  300.             Note: This does not affect usability of the su(1) command.
  301.    *    ENSURE that this file is owned by root.
  302.    *    ENSURE that the permissions on this file are 644.
  303.  
  304.  2.9  Network services
  305.  
  306.   2.9.1  /etc/inetd.conf
  307.     *    ENSURE that the permissions on this file are set to 600.
  308.     *    ENSURE that the owner is root.
  309.     *    DO disable any services which you do not require. 
  310.             - To do this we suggest that you comment out ALL services by 
  311.               placing a "#" at the beginning of each line.  Then enable 
  312.               the ones you NEED by removing the "#" from the beginning 
  313.               of the line.  In particular, it is best to avoid "r" commands 
  314.               and tftp, as they have been major sources of insecurities.  
  315.             - For changes to take effect, you need to restart the inetd 
  316.               process.  Do this by issuing the commands in G.1.  For some 
  317.               systems (including AIX), these commands are not sufficient.
  318.               Refer to vendor documentation for more information.
  319.  
  320.   2.9.2  Portmapper
  321.     *    DO disable any non-required services that are started up in the system 
  322.          startup procedures and register with the portmapper.  See G.2 for a 
  323.          command to help check for registered services.
  324.  
  325.  2.10  Trivial ftp (tftp)
  326.    *    If tftp is not needed, comment it out from the file 
  327.         /etc/inetd.conf and restart the inetd process (as above).
  328.    *    If required, read the AUSCERT Advisory SA-93:05 (see A.1) and follow 
  329.         the recommendations.
  330.  
  331.  2.11  /etc/services
  332.    *    ENSURE that the permissions on this file are set to 644.
  333.    *    ENSURE that the owner is root.
  334.  
  335.  2.12  tcp_wrapper (also known as log_tcp)
  336.    *    ENSURE that you are using this package.
  337.             - Customise and install it for your system.
  338.             - Enable PARANOID mode
  339.             - Consider running with the RFC931 option
  340.             - Deny all hosts by putting "all:all" in /etc/hosts.deny and
  341.               explicitly list trusted hosts who are allowed access to your
  342.               machine in /etc/hosts.allow.
  343.             - See the documentation supplied with this package for details 
  344.               about how to do the above.
  345.    *    DO wrap all TCP services that you have enabled in /etc/inetd.conf
  346.    *    DO consider wrapping any udp services you have enabled.  If you
  347.         wrap them, then you will have to use the nowait option in the 
  348.         /etc/inetd.conf file.
  349.    *    See section B.4 for instructions to obtain tcp_wrapper.
  350.  
  351.  2.13  /etc/aliases
  352.    *    Comment out the "decode" alias 
  353.  
  354.  
  355.  
  356.  
  357. ... texts ...